In packet networks, the elements of the triplet of packet size, data rate and forwarding delay are intrinsically tied to each other. Packets, e.g. Ethernet packets, are typically well adapted in size for the needs of end user applications, in particular for providing a forwarding delay acceptable for the application. At the typical data rates of the end user, the packet size is dimensioned to produce forwarding delays below the human temporal perception horizon. E.g. an Ethernet packet having a size of 1000 bytes takes 125 ms to be filled by voice call data having a data rate of 64 kbit/s, thereby producing a forwarding delay in the range of 125 ms. Thus, applications running at a small end user data rate favor small packet sizes, thereby reducing the forwarding delay to be below the human temporal perception horizon.
In core networks the additional packet-size dependent forwarding delay of packets is lower due to the speed-up from application data rate to core data rate. However, applications (in particular applications with high data rate as video streaming applications having e.g. a data rate of 10 Mbit/s) cannot take benefit from this small forwarding delay because of other delay contributions. E.g. the fiber propagation delay of a span of 1000 km in a core network is in the range of 5 ms (independent of the packet size), whereas in a node of such core network, the packet-size dependent forwarding delay of a packet having a size of 1000 bytes is as low as 1 μs, much lower than all other delay contributions. Thus, the overall additional forwarding delay in the core network is not dominated by the small packet-size dependent forwarding delay in the core network but mostly determined by other delay contributions. The small packet-size dependent forwarding delay in the core network would allow also larger packet sizes. However, as discussed above, typically the packet size is determined by the needs of the user application.
Protocol packets may have even smaller packet sizes. Among the smallest packets is the widely used TCP (transmission control protocol) ACK packet having a size of 64 bytes. This packet is used for acknowledging receipt of a packet in TCP and cannot be avoided in the existing Internet practice.
At the high speed core network, the client traffic is aggregated by volume, nonetheless each individual client packet is forwarded individually in the core. Thus, packet granularity does not change from end user application to the core network. At an ingress node of the core network, each client packet may be separately encapsulated for transmission via the core network by the use of 1:1 encapsulation techniques like T-MPLS (Transport Multiprotocol Label Switching), PBB (Provider Backbone Bridge) or MAC-in-MAC, i.e. one Ethernet packet may be encapsulated in another Ethernet packet. The encapsulated packet is opaque, i.e. not visible for the core network.
At the high data rate in the core network, the immutable packet size as determined by the user application is much too small for efficient transport of the same packet (or 1:1 encapsulated in another packet) in the core network since the header of each packet is processed in the core network. The higher the line rate of the core network, the higher is the effort for header processing. Moreover, the packet processing capabilities of the core network elements have to be designed to be sufficient even in the worst case of maximum load and smallest packet size. Such scenario is unlikely to happen but cannot be safely excluded. Thus, in core network line cards for 10 Gbit/s, 100 Gbit/s and above, e.g. for 100 Gbit/s Ethernet, the header processing of the packets is the most power and silicon area consuming task.
A well known approach for reducing the effort of header processing is the aggregation of smaller size packets into larger size containers, e.g. in optical burst switching (OBS) burstification of packets into larger containers (also called burst or frames) is used. At a network ingress node, packets with the same destination are accumulated and aggregated into a container which in turn is moved as an opaque entity through the core network. Only at the respective network egress node, the container is unloaded and the contained packets are released to the client network. In OBS the aggregation of packets into a container is necessary because of the low switching speed of optical devices. Without aggregation, the optical devices would have to be switched packet-wise which is not possible. In case of electronic or opto-electronic switching the concept of accumulating packets and aggregating the accumulated packets into a container can be also reused for a reduction of the packet count per second in core switches.